home *** CD-ROM | disk | FTP | other *** search
/ Atari Mega Archive 1 / Atari Mega Archive - Volume 1.iso / lists / gem / l_0799 / 715 < prev    next >
Encoding:
Internet Message Format  |  1994-08-27  |  6.2 KB
  1. Date: Fri, 8 Jul 1994 03:11:30 -0400 (EDT)
  2. Date: Thu, 7 Jul 94 22:51:56 EDT
  3. Subject: Gem Listing (fwd)
  4. Subject: Gem Listing
  5. Subject:  Re: Use of the Alternate key
  6. Subject:  Re: available keys
  7. Subject:  Re: available keys
  8. Subject:  Extended object types
  9. Subject:  ^A or ^a or ...
  10. Date: Fri, 8 Jul 1994 03:11:30 -0400 (EDT)
  11. Mime-Version: 1.0
  12. Precedence: bulk
  13.  
  14. Forwarded message:
  15. >From goemon@venice.mps.ohio-state.edu Thu Jul  7 22:52:07 1994
  16. From: Goemon <goemon@venice.mps.ohio-state.edu>
  17. Message-Id: <9407080251.AA06175@venice.mps.ohio-state.edu>
  18. Subject: Gem Listing
  19. To: gem-list-approval@world.std.com
  20. Date: Thu, 7 Jul 94 22:51:56 EDT
  21.  
  22.  
  23.         To: gem-list-approval@world.std.com
  24. Subject:  Re: Use of the Alternate key
  25.  
  26. Ofir: 
  27. >I think it makes sense to leave the Alt key for dialogue shortcuts if your
  28. >dialogues are non-modal. Another possibility is to give the top window
  29. >priority. Alt+[A-Z] should be OK on all keyboards.
  30.  
  31. I totally agree.  That's why most dialog boxes require that you use the
  32. ALT-key combination no matter what...  As for modal dialogs, I believe the
  33. best way to handle that is to disable the menubar if the modal dialog
  34. requires that it be displayed and something be done to it before anything
  35. else can happen.
  36. -----
  37. Subject:  Re: available keys
  38.  
  39. (Whoever),
  40. >I KNOW it's hard, which is why I suggested using a 1-pixel rectangle.
  41. >But others are correct... if you track a 1-pixel rectangle, then you'd 
  42. >have to call objc_find every time the mouse moved, which WOULD cause a 
  43. >lot of overhead.
  44.  
  45. WHAT is so INCREDIBLY DIFFICULT about using objc_find to locate the editable
  46. object under the mouse??  HERE IS SOME EXAMPLE CODE!!!!!!
  47.  
  48. do {
  49.     /* Do your event thingie here and get mouse coords in mx and my */
  50.     object = objc_find(tree, mx, my);
  51.     if (tree[object].ob_flags & EDITABLE)
  52.         graf_mouse(TEXT_CRSR, 0L);
  53.     else
  54.         graf_mouse(ARROW, 0L);
  55. } while(!(exitobject));
  56.  
  57. Total elapsed time : 0.003 microseconds
  58.  
  59. WHAT IS SO DIFFICULT ABOUT THIS?!?!?!?!?!?!?!?!?!?!?!?!?!?!?!  THIS CREATES
  60. THE *SAME* AMOUNT OF TIME THAT THE 1-PIXEL RECTANGLE CREATES!  WHY MUST YOU
  61. KEEP INSISTING ON THE HARD WAY OUT??  Are you *REALLY* a coder?
  62. -----
  63. Subject:  Re: available keys
  64.  
  65. >>> * Selectric      - German
  66. >> yep - the best fileselector around :)
  67. >Yes, although I've started using BoxKite now which is nearly as good and
  68. >supports long filenames with minixfs.
  69.  
  70. BoxKite and Selectric the best?  <laughs>  You've obviously not used UIS.  :)
  71.  
  72. And how many >>GEM<< programs support long filenames? :-)
  73. -----
  74. Subject:  Extended object types
  75.  
  76. Annius:
  77. > I don't understand the fuss about having to define extended object
  78. > types.  There are only 256 ext types and they're there for the
  79. > programmer.  Why try and give world-wide meaning to them and make it
  80. > completely impossible for a programmer to add anything to his/her
  81. > resource files that deviates from the general proposal?
  82.  
  83. I think you COMPLETELY missed what the entire idea of a GEM Master Listing
  84. was for.  Take, for example, the Cookie Master Listing.  GEM Master Listing
  85. provides exactly that same purpose:  It tells programmers which Extended
  86. Object Types (and such) have already been used, and if they wish to make
  87. their programs compatible with those types, they refer to this list.
  88.  
  89. It is extremely practical and extremely useful for the programmers to use
  90. this listing so they know whether or not they are clashing with other
  91. indices.  Remember, some programs write global messages, and if another
  92. program is installed and uses a different GUI, they will clash, and the
  93. other program may even end up crashing.
  94.  
  95. > What would be the advantage of a standard?  That people can exchange
  96. > their resource files?  Why would they want to do that?
  97.  
  98. What if you used some GEM library, say E_GEM. Now say you wrote a program
  99. around it, and then decided to dump E_GEM in favor of some other (newer)
  100. library? If E_GEM didn't follow the listing and decided to assign messages
  101. and indices hodge-podge, your task would be damn near impossible.
  102.  
  103. Also, the indices are there not just to keep programmers from clashing, but
  104. also as a central reference point for this information, instead of having
  105. to refer to 60 separate documents which may or may not be in some consistent
  106. format. By having all the related information in one place in the same format,
  107. writing programs becomes that much simpler.
  108.  
  109. Say for example, you wanted to write your program so that it was compatible
  110. with MultiTOS, Mag!x, Geneva and GEM. Normally you would have to refer to
  111. *AT LEAST* 4 different documents for that information, and they would likely
  112. be in different formats.
  113.  
  114. See the problem?
  115.  
  116. The GEM Master listing is the solution.
  117.  
  118. Also, for programmers wanting to exchange messages and events with other
  119. programs, the GEM Master listing is a handy reference.
  120.  
  121. If you like to live in your own proprietary world and never ever intend on
  122. exchanging messages or events with any other programs, then maybe you don't
  123. need the GEM Master listing.
  124.  
  125. > I also strongly reject the idea that there should be a list where
  126. > everyone can propose their brand new WF/WM codes.  If GEM needs
  127. > new functionality,  make a proposal based on that need.  But it is
  128. > ridiculous to start a discussion by immediately proposing new
  129. > WF/WM codes.
  130.  
  131. Making a proposal would take way too long, and would have to be voted on.
  132. This way your indices can be checked before you allocate them, to make sure
  133. you don't stomp on some other program's codes, and that they remain
  134. compatible. Who knows, maybe looking at the GEM List you will see someone
  135. else's message that does essentially what you need, and by implementing it
  136. you also add compatiblity for your program with that message type.
  137.  
  138. This is analagous to the problem with vector sharing, and is essentially
  139. the reason why XBRA (and the XBRA registration list) was created.
  140.  
  141. If you are so against such standards, then why are you even on this
  142. mailing list?
  143.  
  144. Of course, some people enjoy re-inventing the wheel. Are you one of those
  145. people? :-)
  146.  
  147. > This was of course all MHO.
  148.  
  149. Same here. :-)
  150. --------
  151.  
  152. Subject:  ^A or ^a or ...
  153.  
  154. Ofir Gal: 
  155.  
  156. > > * TrakCom        - Dutch/German
  157. > -> German
  158. Ja!
  159.  
  160. > > * Mag!X          - German
  161. > Now it's MagiC
  162.  
  163. Still unavailable in USA, still doesn't work on anything but german TOS, and
  164. doesn't even work on Falcon030 ?!?! I don't see much of a future in this
  165. one :-)
  166.  
  167. -- Ken Hollis (Bitgate Software)
  168.  
  169.